Prior art computer systems contain non-volatile mass storage devices (e.g. hard disk drives) to hold program and data files. The contents of these files must be loaded into a RAM (“Random Access Memory”) type system memory in order to be accessed or executed by the CPU (“Central Processing Unit”). This operation is typically performed by an operating system on behalf of application programs. Prior art computer systems and operating systems support virtual memory and demand paging. Applications do not directly use system memory addresses to designate the code and data they use; instead they use “virtual addresses” to designate memory locations, which are translated into system memory addresses by a paging mechanism implemented by CPU circuits and controlled by the operating system. This allows the operating system to avoid having to load program and data files in their entirety into RAM. Instead, system memory is divided into chunks of a particular size (called “pages”), and the operating system loads the corresponding chunk of the file contents into each memory page only at the time this specific page is accessed. This process is usually called “demand paging”.
One disadvantage of this method is that RAM is required to hold the contents of programs and data files, reducing the amount of RAM available for other purposes. Also, it typically requires some time to download the contents into RAM. Some prior art computer systems therefore provide a different type of nonvolatile storage devices that can be accessed directly by the CPU in the same manner as RAM (“memory-addressed devices”). One prior art embodiment of a memory-addressed device is a flash memory card. A memory-addressed device allows the CPU to execute code and access data stored on it without first downloading the contents into RAM. This method of directly executing code residing on a memory-addressed device is referred to as “execute-in-place”. In order to provide execute-in-place functionality to applications running on an operating system supporting virtual memory, the operating system has to control the paging mechanism such that certain virtual addresses of an application's address space are mapped to system memory addresses within the range of addresses supported by the memory-addressed device.
Other prior art computer systems provide virtualization capabilities. Virtualization is implemented by a software program, often referred to as “hypervisor” that runs on a single computer system, but allows multiple “guest” operating systems to run concurrently, each in a separate “virtual machine”. Each virtual machine appears to the operating system running within as if it were itself a real computer system, complete with CPU, RAM, and I/O devices. Accesses to these virtual components are intercepted by the hypervisor and translated into accesses to real components. This allows the resources of the computer system to be shared between multiple guest operating systems, providing for increased total utilization of the system resources.
One disadvantage of some prior art virtualized computer systems is that if the same program or data is concurrently accessed by multiple guests running under the same hypervisor, each guest operating system will separately allocate virtual RAM to hold those contents, and the hypervisor may thus have to allocate multiple identical copies of said contents in physical RAM. This means that less memory is available for other purposes, which limits the number of guests that are able to run efficiently simultaneously. Therefore, some prior art hypervisors provide segments of physical memory that can be accessed simultaneously from multiple guests (“shared memory segments”). By storing program or data files into a shared memory segment, multiple guests can access said files simultaneously without first downloading the contents into virtual RAM. Said shared segments appear to the guest operating system as if there were physical memory-addressed devices.
Data and program files are typically stored on devices using a standard file system layout; some operating systems are able to use multiple different file system layouts optimized for different usage scenarios. To enable this, prior art operating systems are typically structured into multiple components. In some operating systems, there is a central file and memory management component, a plurality of file system drivers and a plurality of I/O device drivers. Thus the operating system allows to use any of the supported file system layout on any of the supported I/O devices, by using the appropriate pair of file system driver and I/O device driver in combination with the central file and memory management component. However, prior art operating systems cannot use existing file system drivers to access memory-addressed devices in a fashion that allows for execution in place. Execute-in-place support accessing memory-addressed devices is implemented in a monolithic fashion.
In fact, some prior art operating system implementations do not allow a standard file system layout to be used to store data on memory-addressed devices at all; instead, they require data on such devices to be arranged in ways specific to the device. This arrangement may have multiple disadvantages, in particular for computer systems using both I/O devices and memory-addressed devices. Supporting different file system layouts can make system administration more difficult. Different tools may be required to format, manage, back up and restore different layouts. It may be more difficult to migrate an existing set of files from an I/O device to a memory-addressed device or vice versa. The specific layout required by the memory-addressed device may not provide all features (e.g. to implement sophisticated access control and privilege checks) that are present with standard file system layouts.
Another prior art implementation (the XIP2FS file system for Linux on zSeries) provides support for storing programs and data onto a virtual memory-addressed device (shared memory segments provided by the z/VM hypervisor) using the Second Extended File System (“ext2”) format, one of the standard file system formats provided by the Linux operating system. However, this method still has most of disadvantages described in the previous paragraph: none of the other standard Linux file system formats can be used, and in addition XIP2FS does not provide all features of ext2 (e.g. XIP2FS does not support write access).
Another disadvantage of XIP2FS is that it is not integrated into the above-mentioned component structure of the operating system; even though XIP2FS accesses files using the ext2 file system layout, XIP2FS does not use the Linux ext2 file system driver to do so, but instead re-implements the access logic required to access the ext2 file system layout. This again causes XIP2FS to not support all features of ext2, as only a subset of the full ext2 logic is re-implemented. As further disadvantage, the standard ext2 file system component of the Linux operating system is being developed over time and new features are added; for example the version of the ext2 file system driver provided with Linux kernel version 2.6 added support for faster accesses to very large directory structures as well as more sophisticated access control mechanisms. XIP2FS does not benefit automatically from such enhancements to the ext2 driver; all required features need to be re-implemented within XIP2FS code.